Industrial internet of things data pipeline for a data lake

ABSTRACT

A cloud-based analytics system streams industrial data from customer facilities to a cloud platform as torrential data streams, and performs analytics on the data contained in the data streams based on a selected set of rules. The rules can be designed to diagnose current or potential issues, to monitor for alarm conditions, or to perform other types of analytics. One or more data pipelines migrate data from plant facilities to a data lake residing on the cloud platform. Data streams can be segregated according to customer, and can further be segregated according to plant facility, production area, or any other suitable classification. Each data stream has an associated manifest that identifies the set of rules to be used to process data in each data stream, allowing selected rules to be applied to each data stream in an ad hoc manner.

BACKGROUND

The subject matter disclosed herein relates generally to industrialautomation, and, more particularly, collection and analysis ofindustrial data.

BRIEF DESCRIPTION

The following presents a simplified summary in order to provide a basicunderstanding of some aspects described herein. This summary is not anextensive overview nor is intended to identify key/critical elements orto delineate the scope of the various aspects described herein. Its solepurpose is to present some concepts in a simplified form as a prelude tothe more detailed description that is presented later.

In one or more embodiments, a system for collecting and analyzingindustrial data is provided, comprising a data streaming componentconfigured to transfer industrial data collected from one or moreindustrial devices of an industrial enterprise to a cloud platform as adata stream, wherein the data stream is associated with the industrialenterprise; a harmonization component configured to add harmonizationenvelop data to respective data items of the data stream to yieldharmonized data conforming to a common data schema; and an analyticscomponent configured to reference a manifest associated with theindustrial enterprise, to retrieve one or more analytic rules identifiedby the manifest from a rules store, and to apply the one or moreanalytic rules to one or more of the data items of the data stream toyield one or more analytic results, wherein the data streaming componentis further configured to store the data items and the one or moreanalytic results on cloud-based storage.

Also, one or more embodiments provide a method for monitoring industrialdata, comprising transferring, by a system comprising at least oneprocessor, industrial data collected from one or more industrial devicesof an industrial enterprise to cloud-based storage as a data stream,wherein the data stream is associated with the industrial enterprise;appending, by the system, harmonization envelope data to data items ofthe data stream to yield harmonized data that conforms to a common dataschema; retrieving, by the system, a subset of analytic rules stored oncloud-based rule storage, wherein the subset of the analytic rules areidentified by a manifest associated with the data stream; processing, bythe system, one or more of the data items in accordance with the one ormore analytic rules to yield one or more analytic results; and storing,by the system, the data items and the one or more analytic results onthe cloud-based storage.

Also, according to one or more embodiments, a non-transitorycomputer-readable medium is provided having stored thereon instructionsthat, in response to execution, cause a system to perform operations,the operations comprising transferring industrial data collected fromone or more industrial devices of an industrial enterprise tocloud-based storage as a data stream, wherein the data stream isassociated with the industrial enterprise; appending harmonizationenvelope data to data items of the data stream to yield harmonized datathat conforms to a common data schema; referencing a manifest associatedwith the data stream to identify a subset of analytic rules stored oncloud-based rule storage; processing one or more of the data items inaccordance with the subset of analytic rules to yield one or moreanalytic results; and storing the data items and the one or moreanalytic results on cloud-based storage.

To the accomplishment of the foregoing and related ends, certainillustrative aspects are described herein in connection with thefollowing description and the annexed drawings. These aspects areindicative of various ways which can be practiced, all of which areintended to be covered herein. Other advantages and novel features maybecome apparent from the following detailed description when consideredin conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a high-level overview of an industrial enterprisethat leverages cloud-based services.

FIG. 2 is a block diagram of an example data pipeline and analyticssystem.

FIG. 3 is a high-level diagram of an example cloud-based infrastructurefor a global alarm annunciation broker.

FIG. 4 is a high-level diagram illustrating data streaming and analysisof industrial data on a data lake.

FIG. 5 is a diagram illustrating application of rules against a datastream.

FIG. 6 is a diagram of an example cloud agent device that can reside atthe plant facility and provide data to a cloud-based system.

FIG. 7 is a diagram of a simplified architecture of a cloud-based systemuses a data pipeline and analytics system in connection with performingalarm brokering and other cloud services.

FIG. 8 is a data format diagram illustrating example harmonizationenvelop.

FIG. 9 is a diagram of another view of the data streaming and analyticssystem.

FIGS. 10A and 10B are diagrams illustrating an example data pipelinethat streams data from an industrial site to a cloud-based analyticssystem.

FIG. 11 is a conceptual diagram of an example manifest comprising asystem manifest, one or more tag manifests, and one or more metricsmanifests.

FIG. 12 is an example system manifest.

FIG. 13 is an example tag manifest.

FIG. 14 is an example metrics manifest.

FIG. 15 is an example user interface screen used to define rules thatcan be invoked by a manifest for processing data streams.

FIG. 16 is an example user interface screen that can be used to assignrules to a customer or site via drag-and-drop interaction.

FIG. 17 is an example user interface screen that includes a section fordefining analytic rules.

FIG. 18 is an example user interface screen that includes a section fordefining analytic rules and depicts multiple value attribute fields.

FIGS. 19A and 19B are example Action Configuration displays that can beused to set an action to be performed by a rule.

FIG. 20 is a flowchart of an example methodology for collecting andprocessing industrial data.

FIG. 21 is an example computing environment.

FIG. 22 is an example networking environment.

DETAILED DESCRIPTION

The subject disclosure is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding thereof. It may be evident, however, that the subjectdisclosure can be practiced without these specific details. In otherinstances, well-known structures and devices are shown in block diagramform in order to facilitate a description thereof.

As used in this application, the terms “component,” “system,”“platform,” “layer,” “controller,” “terminal,” “station,” “node,”“interface” are intended to refer to a computer-related entity or anentity related to, or that is part of, an operational apparatus with oneor more specific functionalities, wherein such entities can be eitherhardware, a combination of hardware and software, software, or softwarein execution. For example, a component can be, but is not limited tobeing, a process running on a processor, a processor, a hard disk drive,multiple storage drives (of optical or magnetic storage medium)including affixed (e.g., screwed or bolted) or removable affixedsolid-state storage drives; an object; an executable; a thread ofexecution; a computer-executable program, and/or a computer. By way ofillustration, both an application running on a server and the server canbe a component. One or more components can reside within a processand/or thread of execution, and a component can be localized on onecomputer and/or distributed between two or more computers. Also,components as described herein can execute from various computerreadable storage media having various data structures stored thereon.The components may communicate via local and/or remote processes such asin accordance with a signal having one or more data packets (e.g., datafrom one component interacting with another component in a local system,distributed system, and/or across a network such as the Internet withother systems via the signal). As another example, a component can be anapparatus with specific functionality provided by mechanical partsoperated by electric or electronic circuitry which is operated by asoftware or a firmware application executed by a processor, wherein theprocessor can be internal or external to the apparatus and executes atleast a part of the software or firmware application. As yet anotherexample, a component can be an apparatus that provides specificfunctionality through electronic components without mechanical parts,the electronic components can include a processor therein to executesoftware or firmware that provides at least in part the functionality ofthe electronic components. As further yet another example, interface(s)can include input/output (I/O) components as well as associatedprocessor, application, or Application Programming Interface (API)components. While the foregoing examples are directed to aspects of acomponent, the exemplified aspects or features also apply to a system,platform, interface, layer, controller, terminal, and the like.

As used herein, the terms “to infer” and “inference” refer generally tothe process of reasoning about or inferring states of the system,environment, and/or user from a set of observations as captured viaevents and/or data. Inference can be employed to identify a specificcontext or action, or can generate a probability distribution overstates, for example. The inference can be probabilistic—that is, thecomputation of a probability distribution over states of interest basedon a consideration of data and events. Inference can also refer totechniques employed for composing higher-level events from a set ofevents and/or data. Such inference results in the construction of newevents or actions from a set of observed events and/or stored eventdata, whether or not the events are correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom the context, the phrase “X employs A or B” is intended to mean anyof the natural inclusive permutations. That is, the phrase “X employs Aor B” is satisfied by any of the following instances: X employs A; Xemploys B; or X employs both A and B. In addition, the articles “a” and“an” as used in this application and the appended claims shouldgenerally be construed to mean “one or more” unless specified otherwiseor clear from the context to be directed to a singular form.

Furthermore, the term “set” as employed herein excludes the empty set;e.g., the set with no elements therein. Thus, a “set” in the subjectdisclosure includes one or more elements or entities. As anillustration, a set of controllers includes one or more controllers; aset of data resources includes one or more data resources; etc.Likewise, the term “group” as utilized herein refers to a collection ofone or more entities; e.g., a group of nodes refers to one or morenodes.

Various aspects or features will be presented in terms of systems thatmay include a number of devices, components, modules, and the like. Itis to be understood and appreciated that the various systems may includeadditional devices, components, modules, etc. and/or may not include allof the devices, components, modules etc. discussed in connection withthe figures. A combination of these approaches also can be used.

Industrial controllers and their associated I/O devices are central tothe operation of modern automation systems. These controllers interactwith field devices on the plant floor to control automated processesrelating to such objectives as product manufacture, material handling,batch processing, supervisory control, and other such applications.Industrial controllers store and execute user-defined control programsto effect decision-making in connection with the controlled process.Such programs can include, but are not limited to, ladder logic,sequential function charts, function block diagrams, structured text, orother such programming structures.

Because of the large number of system variables that must be monitoredand controlled in near real-time, industrial automation systems oftengenerate vast amounts of near real-time data. In addition to productionstatistics, data relating to machine health, alarm statuses, operatorfeedback (e g , manually entered reason codes associated with a downtimecondition), electrical or mechanical load over time, and the like areoften monitored, and in some cases recorded, on a continuous basis. Thisdata is generated by the many industrial devices that make up a typicalautomation system, including the industrial controller and itsassociated I/O, telemetry devices for near real-time metering, motioncontrol devices (e.g., drives for controlling the motors that make up amotion system), visualization applications, lot traceability systems(e.g., barcode tracking), etc. Moreover, since many industrialfacilities operate on a 24-hour basis, their associated automationsystems can generate a vast amount of potentially useful data at highrates. The amount of generated automation data further increases asadditional plant facilities are added to an industrial enterprise.

Industrial automation systems that make up a given industrial enterpriseare typically maintained by on-site plant personnel (e.g., maintenancepersonnel, plant engineers, etc.). Given the diversity and complexity ofindustrial assets that make up a given industrial system, many device orsystem maintenance issues require a level of specialized deviceexpertise not possessed by on-site maintenance personnel, who may beresponsible for a wide range of disparate industrial assets andtherefore possess a more generalized knowledge of their assets.Consequently, industrial enterprises generally rely, to varying degrees,on outside expert support personnel for assistance with certaintechnical support issues.

Maintenance personnel wishing to obtain technical assistance to resolvea device failure, a performance issue, or an alarm incident musttypically contact a remote technical support person by phone and providerelevant information about their particular industrial device, software,system configuration, etc. Providing the technical support personnelwith a complete set of relevant information required to resolve amaintenance issue sometimes requires a level of knowledge about thecustomer's system that on-site plant personnel may not possess.Moreover, on-premise maintenance personnel may not know the correcttechnical support person for assistance in solving a particular alarmincident. This is a particular problem in the case of custom-builtindustrial systems, which are often designed and built by originalequipment manufacturers (OEMs) using devices supplied by a separateequipment vendor (e.g., industrial controllers, motor drives, etc.).Consequently, the most suitable technical support entity for addressinga particular performance issue or abnormality with the custom machinemay not always be clear to the machine owner.

To address these and other issues, one or more embodiments of thepresent disclosure relate to a cloud-based system that streamsindustrial data from customer facilities to a cloud platform as datastreams, and performs analytics on the data contained in the datastreams based a set of rules. The rules can be designed to diagnosecurrent or potential issues, and the system can interface with an alarmbrokering system that assists in locating suitable technical supportpersonnel in response to detected incidents. The system architectureincludes one or more data pipelines that migrate data from plantfacilities to a data lake residing on the cloud platform. For systems inwhich data from multiple different industrial enterprises is monitored,the data streams can be segregated by industrial enterprise (customer),and can further be segregated according to any other suitable criterion(e.g., plant facility, production area, etc.). Each data stream has anassociated manifest that identifies the set of rules to be used toprocess data in each data stream, allowing selected rules to be appliedto each data stream in an ad hoc manner

The industrial uptime system described herein can execute as a serviceor set of services on a cloud platform. FIG. 1 illustrates a high-leveloverview of an industrial enterprise that leverages such cloud-basedservices. The enterprise comprises one or more industrial facilities104, each having a number of industrial devices 108 and 110 in use. Theindustrial devices 108 and 110 can make up one or more automationsystems operating within the respective facilities 104. Exemplaryautomation systems can include, but are not limited to, batch controlsystems (e.g., mixing systems), continuous control systems (e.g., PIDcontrol systems), or discrete control systems. Industrial devices 108and 110 can include such devices as industrial controllers (e.g.,programmable logic controllers or other types of programmable automationcontrollers); field devices such as sensors and meters; motor drives;operator interfaces (e.g., human-machine interfaces, industrialmonitors, graphic terminals, message displays, etc.); industrial robots,barcode markers and readers; vision system devices (e.g., visioncameras); smart welders; or other such industrial devices.

Exemplary automation systems can include one or more industrialcontrollers that facilitate monitoring and control of their respectiveprocesses. The controllers exchange data with the field devices usingnative hardwired I/O or via a plant network such as Ethernet/IP, DataHighway Plus, ControlNet, Devicenet, or the like. A given controllertypically receives any combination of digital or analog signals from thefield devices indicating a current state of the devices and theirassociated processes (e.g., temperature, position, part presence orabsence, fluid level, etc . . ), and executes a user-defined controlprogram that performs automated decision-making for the controlledprocesses based on the received signals. The controller then outputsappropriate digital and/or analog control signaling to the field devicesin accordance with the decisions made by the control program. Theseoutputs can include device actuation signals, temperature or positioncontrol signals, operational commands to a machining or materialhandling robot, mixer control signals, motion control signals, and thelike. The control program can comprise any suitable type of code used toprocess input signals read into the controller and to control outputsignals generated by the controller, including but not limited to ladderlogic, sequential function charts, function block diagrams, structuredtext, or other such platforms.

Although the exemplary overview illustrated in FIG. 1 depicts theindustrial devices 108 and 110 as residing in fixed-location industrialfacilities 104, the industrial devices 108 and 110 may also be part of amobile control application, such as a system contained in a truck orother service vehicle.

According to one or more embodiments, on-premise cloud agents 106 cancollect data from industrial devices 108 and 110—or from other datasources, including but not limited to data historians, business-levelsystems, etc.—and send this data to cloud platform 102 for processingand storage. Cloud platform 102 can be any infrastructure that allowscloud services 112 to be accessed and utilized by cloud-capable devices.Cloud platform 102 can be a public cloud accessible via the Internet bydevices having Internet connectivity and appropriate authorizations toutilize the services 112. In some scenarios, cloud platform 102 can beprovided by a cloud provider as a platform-as-a-service (PaaS), and theservices 112 (such as the alarm annunciation brokering system describedherein) can reside and execute on the cloud platform 102 as acloud-based service. In some such configurations, access to the cloudplatform 102 and the services 112 can be provided to customers as asubscription service by an owner of the services 112. Alternatively,cloud platform 102 can be a private or semi-private cloud operatedinternally by the enterprise, or a shared or corporate cloudenvironment. An exemplary private cloud can comprise a set of servershosting the cloud services 112 and residing on a corporate networkprotected by a firewall.

Cloud services 112 can include, but are not limited to, data storage,data analysis, control applications (e.g., applications that cangenerate and deliver control instructions to industrial devices 108 and110 based on analysis of real-time system data or other factors), alarmmonitoring and expertise brokering services, visualization applicationssuch as the cloud-based operator interface system described herein,reporting applications, Enterprise Resource Planning (ERP) applications,notification services, or other such applications. Cloud platform 102may also include one or more object models to facilitate data ingestionand processing in the cloud. If cloud platform 102 is a web-based cloud,cloud agents 106 at the respective industrial facilities 104 mayinteract with cloud services 112 directly or via the Internet. In anexemplary configuration, the industrial devices 108 and 110 connect tothe on-premise cloud agents 106 through a physical or wireless localarea network or radio link. In another exemplary configuration, theindustrial devices 108 and 110 may access the cloud platform 102directly using integrated cloud agents.

Ingestion of industrial device data in the cloud platform 102 can offera number of advantages particular to industrial automation. For one,cloud-based storage offered by the cloud platform 102 can be easilyscaled to accommodate the large quantities of data generated daily by anindustrial enterprise. Moreover, multiple industrial facilities atdifferent geographical locations can migrate their respective automationdata to the cloud for aggregation, collation, collective analysis,visualization, and enterprise-level reporting without the need toestablish a private network between the facilities. Cloud agents 106 canbe configured to automatically detect and communicate with the cloudplatform 102 upon installation at any facility, simplifying integrationwith existing cloud-based data storage, analysis, or reportingapplications used by the enterprise. In another example application,cloud-based diagnostic applications can monitor the health of respectiveautomation systems or their associated industrial devices across anentire plant, or across multiple industrial facilities that make up anenterprise. Cloud-based lot control applications can be used to track aunit of product through its stages of production and collect productiondata for each unit as it passes through each stage (e.g., barcodeidentifier, production statistics for each stage of production, qualitytest data, abnormal flags, etc.). Moreover, cloud based controlapplications can perform remote decision-making for a controlledindustrial system based on data collected in the cloud from theindustrial system, and issue control commands to the system via thecloud agent. These industrial cloud-computing applications are onlyintended to be exemplary, and the systems and methods described hereinare not limited to these particular applications. The cloud platform 102can allow software vendors to provide software as a service, removingthe burden of software maintenance, upgrading, and backup from theircustomers.

FIG. 2 is a block diagram of an example data pipeline and analyticssystem 202 according to one or more embodiments of this disclosure.Aspects of the systems, apparatuses, or processes explained in thisdisclosure can constitute machine-executable components embodied withinmachine(s), e.g., embodied in one or more computer-readable mediums (ormedia) associated with one or more machines. Such components, whenexecuted by one or more machines, e.g., computer(s), computingdevice(s), automation device(s), virtual machine(s), etc., can cause themachine(s) to perform the operations described.

Data pipeline and analytics system 202 can include one or more datastreaming components 204, a manifest assembly component 206, a rulesdefinition component 208, a harmonization component 210, an analyticscomponent 212, a user interface component 214, one or more processors216, and memory 218. In various embodiments, one or more of the datastreaming component(s) 204, manifest component 206, rules definitioncomponent 208, harmonization component 210, analytics component 212,user interface component 214, the one or more processors 216, and memory218 can be electrically and/or communicatively coupled to one another toperform one or more of the functions of the data pipeline and analyticssystem 202. In some embodiments, components 204, 206, 208, 210, 212, and214 can comprise software instructions stored on memory 218 and executedby processor(s) 216. Data pipeline and analytics system 202 may alsointeract with other hardware and/or software components not depicted inFIG. 2. For example, processor(s) 216 may interact with one or moreexternal user interface devices, such as a keyboard, a mouse, a displaymonitor, a touchscreen, or other such interface devices.

The one or more data streaming components 204 can be configured tomanage migration of data from industrial facilities to the cloudplatform. In one or more embodiments, the system can facilitatemigration of data from industrial data sources on the plant floor usingproduce clients and consume clients, which yield torrential data streamsfrom the plant floor to a data lake on the cloud platform. The manifestcomponent 206 can be configured to create, update, and managecustomer-specific manifests on the cloud platform. The manifests defineand implement customer-specific processing of the data streams in termsof one or more defined processing rules. The rules definition component208 can be configured to process user input that defines the one or morerules (e.g., rules 220) and store these rules in a rules library forinvocation by the customer-specific manifests.

The harmonization component 210 can be configured to apply aharmonization envelop to incoming data (e.g., industrial alarm and eventdata) received via the data streams, thereby normalizing data frommultiple different sources so that the data can be processed in aconsistent manner by the rules created by the rules definition component208 and invoked by the manifests. Analytics component 212 can beconfigured to process harmonized data received via the data streams inaccordance with one or more rules invoked by the manifests associatedwith the respective data streams. The user interface component 214 canbe configured to exchange information between the system 202 and aclient device associated with an administrator, technical expert, systemmanager, a supervisor, or another authorized user of the data pipelineand analytics system 202. To this end, the user interface component 214can be configured to serve user interface screens to the client devicethat allow the user to view information stored or generated by thesystem 202 (e.g., rules definition screens, alarm status information,expert information, alarm service histories, etc.) and to sendinformation to the system 202 (e.g., rules definitions, serviceacknowledgements, availability information, contact information, etc.).

The one or more processors 216 can perform one or more of the functionsdescribed herein with reference to the systems and/or methods disclosed.Memory 218 can be a computer-readable storage medium storingcomputer-executable instructions and/or information for performing thefunctions described herein with reference to the systems and/or methodsdisclosed.

In some implementations, the industrial data pipeline and analyticssystem described herein can be used in connection with a global alarmannunciation broker that assists in locating and contacting suitabletechnical support personnel in response to detected alarm incidents at aplant facility. FIG. 3 is a high-level diagram of an example cloud-basedinfrastructure for a global alarm annunciation broker. The broker system304 is configured to search a global expert network for appropriatetechnical support resources in response to detecting alarm conditions atvarious customer sites 306 (e.g., industrial facilities) requiringexpert assistance. The broker system 304 employs a “follow-the-sun”approach to identifying an available technical support resource asquickly as possible to address a detected alarm event. For example, whenan alarm event is identified based on analysis of harmonized alarmbatches received via the data streams described herein, the brokersystem 304 first performs a search of local technical support resourceswithin the same geographical region from which the alarm was received.If no suitable local technical support resource is found, or if localtechnical support experts are not available (e.g., due to the time atwhich the alarm event occurred), the broker system 304 can expand thetechnical support search to other geographical regions. For example, thebroker system 304 may generate a technical support ticket for an alarmevent detected at a European facility during an overnight shift. In thisscenario, the broker system 304 may initially perform a technicalsupport search that is limited to Europe. However, since the alarm eventwas generated during the overnight shift, European technical experts 302capable of assisting with the alarm event may not be available at thattime. The system can make a determination regarding availability oftechnical support personnel based on availability data maintained on acloud-based expert database. Since no suitable technical support expertsare available in Europe at the time the alarm event was detected, thebroker system 304 can extend the search for a technical resource to aregion in another time zone—e.g., North America—where technical supportexperts 308 are more likely to be available at that time. In general,the cloud platform serves as a seamless conduit to realize theseinter-regional connections.

In general, broker system 304 responds to detected alarm conditions byfirst searching local support resources, and scaling up if localresources cannot be found or are not available at the particular timeand zone of need. This process of scaling up can eventually move acrossregions. Every brokering action depends on a set of rules that specifiedfor respective customers (e.g. industrial enterprises comprising one ormore industrial sites). The broker system 304 leverages a rules engineto process various customer-level application rules, where the rulesengine encodes brokering intelligence. In an example scenario, thebroker system 304 may try to match technical experts to an alarm eventin the European region but cannot find support resources at that time inEurope. However, the broker system 304 may then find technical supportexpertise capable of handling the issue in North America at that time.This high-level rule, applicable to all managed cases, can specify thatan alarm event originating in the European region is to be matched to aresource in the North American region until a local resourceacknowledges the request for local servicing.

The Internet or cloud platform is a seamless conduit that realizes theseinter-regional connections. The subscription system that connects thedata lake with the broker system 304 permits this type of global reach.An expert-level database partitions expert-level data to help the brokersystem 304 to perform incremental search and selection of matchingresources to serve alarm events in an order that is specified byapplication-level and meta-level rules.

The pipeline and analysis architecture described herein can implement asubscription layer that harmonizes and pushes alarm data and other typesof data from industrial sites to the data lake leveraged by brokersystem 304, which will associate alarms and alarm patterns withtechnical service support for the various industrial sites. The pipelineand analytics system 202 can migrate data from various industrial sitesas distinct data and apply customer-specific rules to each data streamfor various purposes prior to storage on the cloud platform. In additionto alarm brokering, other types of cloud-based analysis can be performedon the data to support a number of different applications. To facilitatesystem flexibility and scalability, the data streaming and analytics canbe performed on a data lake, which allows heterogeneous data to bestored in a raw format without extensive preprocessing (e.g., extracttransform load, or ETI, processing). FIG. 4 is a high-level diagramillustrating data streaming and analysis of industrial data on a datalake according to one or more embodiments. In this example, data lake402 resides on a cloud infrastructure (e.g., a private cloud, or apublic cloud that offers infrastructure-as-a-service).

The data pipeline and analytics system 202 works in connection with thedata lake 402 to stream data from a variety of industrial data sources404, including but not limited to industrial robots, motor drives (e.g.,variable frequency drives or other types of drives), industrialcontrollers, or industrial machines or their associated control devices.As will be described in more detail herein, the data streaming servicesimplemented by system 202 can perform user-defined analytics onindividual data streams, where the analytics applied to a data streamdepends in part on the source of the data contained in the stream.Analysis can be carried out on the data lake using distributedprocessing techniques made possible by the scalable computing resourcesof the data lake. In some embodiments, after stream analysis has beenperformed on the data streams, the data and any analytical results canbe either stored on cloud-based storage in customer-specific datastorage, or can be placed in defined data queues for queue analysis. Anumber of different types of applications 406 can leverage the data andanalysis results generated and stored on the cloud platform, includingbut not limited to reporting applications, interactive web and mobileapplications, enterprise applications, etc.

As noted above, the system described herein performs stream-levelanalysis on the industrial data streams that migrate data from theindustrial sites to the cloud system. FIG. 5 is a diagram illustratingapplication of rules against a data stream. In this example, the datastreaming components 204 of the data pipeline and analytics system 202(e.g., one or more produce clients and consume clients) migrate datagenerated by one or more data sources at an industrial facility (i.e., acustomer site) to cloud-based big data storage by streaming the datafrom the data sources to the cloud as torrential data, yielding a datastream 504. The streamed data can include, for example, time-series datagenerated by sensors on the plant floor (e.g., temperature sensors, flowmeters, pressure sensors, level sensors, proximity switches, etc.);alarm data generated by an industrial controller, a motor drive, asafety controller, a quality check system, etc.; or other types of data.

In some embodiments, the data stream 504 can comprise data collectedfrom the respective industrial devices at the plant facility by adedicated on-premise cloud agent device, which interfaces with the datapipeline and analytics system 202 to facilitate streaming of torrentialdata to the cloud-base system. Turning briefly to FIG. 6, an examplecloud agent device 640 that can reside at the plant facility and providedata to the cloud-based system 202 is illustrated. In this exampletechnique, on-premise data collection is enabled by a collection ofservices that function to process and send collected industrial data tothe cloud-based data pipeline. Data concentrator 628 and cloud agentdevice 640 respectively implement two main functions associated withdata collection—data concentration using a historian 638 and associateddata storage 636 (e.g., an SQL server or other type of storage), andcloud data enablement using cloud agent services executed by cloud agentdevice 640. Plant data 610 from one or more industrial devices iscollected by data concentrator 628 at the plant facility. In an examplescenario, plant data 610 may comprise stamping press time-series sensordata, made up of thousands of data points updated at a rate of less thana second. Plant data 610 can also comprise alarm data generated by oneor more industrial devices in response to detected alarm events.

Collection services component 602 of cloud agent device 640 implementscollection services that collect device data, either from dataconcentrator's associated data storage (e.g., via an SQL query) ordirectly from the devices themselves via a common industrial protocol(CIP) link or other suitable communication protocol. For example, toobtain data from data concentrator 628, collection services component602 may periodically run a data extraction query (e.g., an SQL query) toextract data from data storage 636 associated with data concentrator628. Collection services component 602 can then compress the data andstore the data in a compressed data file 612. Queue processing servicesexecuted by queue processing component 604 can then read the compresseddata file 612 and reference a message queuing database 614, whichmaintains and manages customer-specific data collection configurationinformation, as well as information relating to the customer'ssubscription to the cloud platform and associated cloud services. Basedon configuration information in the message queuing database 614, queueprocessing component 604 packages the compressed data file 612 into adata packet and pushes the data packet to the data pipeline andanalytics system 202 on the cloud platform. In conjunction with the datastreaming components 204 of system 202, the cloud agent device 640 caninject the data as torrential data 616.

Message queuing database 614 can include site-specific informationidentifying the data items to be collected (e.g., data tag identifiers),user-defined processing priorities for the data tags, firewall settingsthat allow cloud agent device 640 to communicate with the cloud platformthrough a plant firewall, and other such configuration information.Configuration information in message queuing database 614 can instructcloud agent device 640 how to communicate with the identified data tagsand with the remote data collection services on the cloud platform.

In addition to collection and migration of data, one or more embodimentsof cloud agent device 640 can also perform local analytics on the dataprior to moving the data to the cloud platform. This can comprisesubstantially any type of pre-processing or data refinement that mayfacilitate efficient transfer of the data to the cloud, prepare the datafor enhanced analysis in the cloud, reduce the amount of cloud storagerequired to store the data, or other such benefits. For example, cloudagent device 640 may be configured to compress the collected data usingany suitable data compression algorithm prior to migrating the data tothe cloud platform. This can include detection and deletion of redundantdata bits, truncation of precision bits, or other suitable compressionoperations. In another example, cloud agent device 640 may be configuredto aggregate data by combining related data from multiple sources. Forexample, data from multiple sensors measuring related aspects of anautomation system can be identified and aggregated into a single cloudupload packet by cloud agent device 640. Cloud agent device 640 may alsoencrypt sensitive data prior to upload to the cloud. In yet anotherexample, cloud agent device 640 may filter the data according to anyspecified filtering criterion (e.g., filtering criteria defined in afiltering profile stored on the cloud agent). For example, definedfiltering criteria may specify that pressure values exceeding a definedsetpoint are to be filtered out prior to uploading the pressure valuesto the cloud.

Cloud agent device 640 may also associate metadata with selected subsetsof the data prior to migration to the cloud, thereby contextualizing thedata within the industrial environment. For example, cloud agent device640 can tag selected subsets of the data with a time indicatorspecifying a time at which the data was generated, a quality indicator,a production area indicator specifying a production area within theindustrial enterprise from which the data was collected, a machine orprocess state indicator specifying a state of a machine or process atthe time the data was generated, a personnel identifier specifying anemployee on duty at the time the data was generated, or other suchcontextual metadata. In some embodiments, the cloud agent device 640 canalso aggregate the data with external data retrieved from externalsources (e.g., weather data, stock market price data, etc.) In this way,cloud agent device 640 can perform layered processing of the collecteddata to generate meta-level knowledge that can subsequently be leveragedby cloud-based analysis tools to facilitate enhanced analysis of thedata in view of a larger plant context.

To ensure secure outbound traffic to the cloud, one or more embodimentsof cloud agent device 640 can support HTTPS/SSL, certificate authorityenabled transmission, and/or unique identity using MAC addresses. Cloudagent device 640 can also support store-and-forward capability to ensuredata is not lost if the agent becomes disconnected from the cloud.

Returning now to FIG. 5, the data stream 504 can be customer-specific,and may include data from multiple different devices, machines, and/orfacilities. As the data is being streamed from the plant facility tocloud-based storage, analytics component 212 can process selectedsubsets of the data based on one or more defined rules 220. Users of thesystem 202 can define rules 220 using rules definition component 208,which can serve one or more rule configuration screens (described inmore detail below) to authorized client devices to facilitate creationof rules and association of those rules to specified data streams. Userscan author rules 220 based on their knowledge of the industrial systemsfrom which the respective data streams are received. For example, amaintenance expert responsible for a particular machine for which datais being streamed may define a rule that causes a notification event orother action 508 to be issued if a particular event relating to themachine occurs (e.g., if a winder current increases past a specifiedsetpoint value for a defined duration of time). The analytics component212 runs continuously or substantially continuously to apply theknowledge rules 220 to the torrential data contained in the data stream504, regardless of the source of the data.

The manifest component 206 can be used to define which rules 220 are tobe applied to each data stream 504. In general, a manifest defines amapping between a source of data (e.g., a customer, facility, and/ormachine associated with a particular data stream) and a procedure to beperformed on that data, where the procedure is represented by a selectedsubset of the defined rules 220. For example, a manifest can comprisemetadata stored on cloud storage in association with a particular datastream (which is itself associated with a particular source of data),where the manifest can identify one or more predefined or generic rulesto be applied to that data stream. The manifest can also identify theparticular items of streaming data that are to be used as the parametersor variable inputs for the rules, and any upper or lower limits to beenforced on the variables or on the rule outputs. In this manner, themanifest allows predefined or generic rules to be applied in an ad hocmanner for each customer whose data is being collected and monitored.Manifest component 206 can facilitate creation and management ofcustomer-specific manifests; e.g., by implementing a manifest generationtool that allows a user to associated rule with the respective datastreams.

The data contained in data stream 504 can be classified into distincttypes of information. Example data types include time-series sensor dataand alarm data (alarm data can also be classified together with faultand event data). Alarms, faults, and events can be generated by a numberof different on-premise data sources, including but not limited toindustrial controllers and drives, dedicated alarm monitoring systems(e.g., low and medium voltage drives monitoring systems), surveillancesystems with dedicated virtual private networks (see FIG. 3) or othersuch sources. For data falling under this category, users may wish todistinguish between events, alarms, and faults. Events may be defined asnormal operational statuses of different devices that are part of one ormore industrial systems (e.g., a start button has been pressed, aproximity switch has been activated, a valve has been closed, etc.).Alarms can be defined as detected statuses that indicate potentialproblems. For example, if a monitored motor current exceeds a definedsetpoint, the motor may continue to run, but may eventually result in amotor fault if the current level is not reduced. Alarms can preemptivelywarn operators or maintenance personnel that a preventative action maybe necessary to prevent a system failure or downtime occurrence. Faultscan be defined as a failure or downtime condition detected within thesystem (e.g., an encoder value has been lost, a fuse has been blown, anemergency stop condition has occurred, etc.).

Time-series sensor data may originate from industrial controllers,drives, telemetry devices, or other such industrial devices. This datacan include data point information (e.g., temperatures, pressures, etc.)that reflects process information relating to an industrial processbeing monitored and/or controlled by the industrial devices. Time-seriessensor data can be useful for remote proactive or predictive analysis ofthe industrial process.

The pipeline and analytics system 202 can ingest both of these types ofdata (as well as other data types in some embodiments) into the datastream 504 and apply analytical rules to selected subsets of the data inaccordance with metadata defined by the manifests, before storing thedata (as well as any additional analytical result data generated byapplying the rules) in cloud-based storage 506.

FIG. 7 is a diagram of a simplified architecture of a cloud-based systemuses data pipeline and analytics system 202 in connection withperforming alarm brokering and other cloud services. In this example,the cloud-based system receives alarm and time-series sensor data (TSSD)702 from multiple industrial facilities associated with differentindustrial enterprises or customers (e.g., from cloud agent devices orother monitoring systems. Data streaming components 204 of the pipelineand analytics system 202 migrates this diverse data to the cloud systemas torrential data within segregated data streams, where the datacontained each data stream corresponds to a particular customer,facility, and/or machine. The system can apply any defined filteringrules to the streaming alarm data at 704.

Before the data is moved to the alarm brokering system, the alarm andevent data is harmonized at 706 (e.g., by harmonization component 210)to a common schema by adding a harmonization envelope to respectiveitems of alarm data. Harmonization of the alarm data can bridge the datalake to the alarm brokering functionality. To this end, theharmonization component 210 can gather alarms from different sourcesinto batches, apply alarm harmonization to the batch of alarms, andtransfer the harmonized data to the alarm brokering system via asubscription channel into a brokering level entry queue. The entry queuewill provide acknowledgements back to the harmonization component 210(e.g., success, failure not available, etc.). The harmonizationcomponent 210 can use the acknowledgements from the brokering system tomanage the alarm batch status. The alarm batches will be indexed in sucha way that an organized batch table structure can be established.

Alarm harmonization creates a common schema around the alarm data byadding a harmonization envelop to the original alarm structure whilekeeping the original format of the alarms. Turning briefly to FIG. 8, anexample harmonization envelop is illustrated. The common schema affordedby the harmonization process allows rules—such as business intelligencerules or other types of rules—to be organized around the data to processthe alarms in an efficient and consistent manner Subsequently, alarmsmoved from the on-premise data sources to the data lake corresponding toraw-level alarms.

Each raw-level alarm can contain information that assist in identifyingthe locale of origin, alarm description, and time stamp representing thetime that the alarm was generated. To create an alarm batch, eachraw-level alarm is harmonized according to the schema shown in FIG. 8.To create an alarm batch, the harmonization component can harmonize eachraw-level alarm by adding fields for the Time Zone, Technology, Status,Mode, and Filter Key to each alarm record. The Time Zone fieldidentifies a time zone of origin for the alarm. The Technology fieldidentifies a particular technology to which the alarm relates, which canbe used by the brokering services to identify a suitable set oftechnical experts for addressing the alarm event identified by thealarm. The Status field can identify a current processing status of thealarm—e.g., In Process, Waiting, Served, Escalated, or Completed. TheMode field indicates a mode of the alarm record—e.g., Filtered,Correlated, Base, Managed, or Master. The filter key can identify afield (e.g. the Application ID or Technology fields) to be used as afilter key. The Rework field can be used to track the number of attemptsmade by the brokering system to process the alarm. It is to beappreciated that the harmonization schema illustrated in FIG. 8 is onlyintended to be exemplary, and that any suitable schema can be used toharmonize the alarm data records without deviating from the scope ofthis disclosure. The harmonization process prepares the alarminformation for the alarm brokering functionality carried out by thecloud-based brokering system.

Returning now to FIG. 7, additional alarm filtering may be performed onthe harmonize alarms at 708 (advanced alarm filter rules engine). Then,each harmonized alarm is accumulated in a transferring batch prior totransmission to the brokering system. The size and the batch and itstransmission rate are set by configuration settings that can becontrolled by a system manager during the system configuration phase(e.g., via a system user interface). A given alarm batch can contain amix of alarms that emerge from various industrial systems that are beingmonitored on a per customer basis. The cloud-based system maintainscustomer data sovereignty throughout the alarm processing. The resultingalarm batches are then stored on cloud-based storage 710 for batchanalysis by broker processing functionality 712. A notification engine714 can notify one or more experts 716 (selected based on the alarmbrokering process) if results of the alarm processing indicate an eventthat merits attention by technical support personnel. In such scenarios,the notification engine 714 can generate information relating to thedetected alarm event and store this information in cloud storage 718accessible to the notified experts. Results of the processing can alsobe leveraged by other applications, such as business intelligenceapplications 720.

As will be described in more detail below, the alarm filtering,harmonization, and other rule-based analytics are carried on respectivedata streams as the customer-specific data is being migrated to the datalake from the various industrial facilities and industrial enterprises.

FIG. 9 is a diagram that provides another view of the data streaming andanalytics system. As described above, data ingestion services 902 (e.g.,implemented by cloud agent devices) collect time-series sensor dataand/or alarm data from industrial devices at a plant facility and streamthe collected data to the data lake on the cloud platform as torrentialdata. In the case of alarm data, the data is received at the cloudplatform as raw alarm data, which is then harmonized as described aboveby harmonization processes 904 (in some configuration, the cloud-basedsystem may include alarm handler services that perform some initialalarm processing or handling on the raw alarm data prior toharmonization). The harmonized alarm data can be processed by alarmhandling services 908, and/or filtered and processed by filtering/ruleservices 910 (e.g., implemented by analytics component 212). Thefiltered and processed alarms can then be indexed in cloud storage 922on the data lake by indexing services 912.

The rules applied by the filtering/rule services 910 can be stored indata storage 914, segregated according to data stream. That is, eachdata stream corresponds to a particular industrial enterprise,industrial facility, and/or industrial system or process, and a set ofrules are defined for each data stream and stored in data storage 914.In this way, customer-specific analytics are performed on each datastream, where the analytics rules applied to each stream are partly afunction of where the data originates. Rules services 916 (e.g.,implemented by the rules definition component 208) allow users to defineand store rules to be applied to the data streams via rule definitioninterface displays rendered by the user interface 918 associated withthe cloud system (e.g., implemented by user interface component 214).Example rule definition interface displays and work flows will bedescribed in more detail below. Uptime services 920—including alarmbrokering services, notification services, reporting services, etc.—cansend updated alarms or other information relating to the indexed data toauthorized users via the user interface 918.

The term data pipeline is used to represent the workflow of data fromthe plant facility to the data lake (e.g., the data lake associated withcloud storage 922) and the processing stages that take place during thismigration. This data pipeline is described in more detail with referenceto the function blocks depicted in FIGS. 10A and 10B. In this exampleimplementation, streaming of data from the industrial data sources 1002at the plant facility is implemented by an event produce client 1004 onthe plant floor and an event consume client 1006 that executes on thecloud platform. The event produce client 1004 (which may be implementedby a cloud agent device, such as cloud agent device 640) queries localdata sources for data at regular intervals, and publishes the data forretrieval by the event consume client 1006. This produce/consumeconfiguration yields an event driven architecture that isolatesrespective data processing steps that takes place in the pipeline. Thisconfiguration also renders the pipeline scalable, since new eventproduce clients 1004 can be added that provide data to the same eventconsume client 1006, and new data stream processing workflows can beadded to the pipeline after the data consume client 1006.

The consume client 1006 routes the raw industrial data from the produceclient 1004 to downstream transformation and analytic processing,including the harmonization processing block 1008 (implemented byharmonization component 210). Also, to facilitate internal tracking andrecord-keeping, raw (pre-harmonized) data and results of any associatedprocessing (e.g., processing carried out by alarm handler services 906)is stored on distributed cloud storage by a data store stages 1010.

The raw data is harmonized at the harmonization processing block 1008 asdescribed above, and the harmonized alarm data is saved. The harmonizeddata is routed by another produce/consume client pair (comprisingproduce client 1014 and consume client 1012) to further other downstreamtransformation and analysis processes, illustrated in FIG. 10B. The ruleprocessing block 1016 applies user-defined alarm rules to the harmonizedalarm (or TSSD) data, including but not limited to alarm inhibitingrules, masking and filtering rules, and monitoring rules.

Alarm inhibit rules can be designed to inhibit alarms at the individualalarm level, as well as at the device or process level, as defined bythe manifest 1028 (to be described in more detail below). Such inhibitrules may be created, for example, by support experts or end users inorder to control or reduce the effective workload generated by alarmdata. For example, inhibit rules applied to data streams by processingblock 1016 (implemented by analytics component 212) may define thatcertain types of alarms, or alarms from specified devices, processes, orindustrial systems, are not to generate an alarm notification orinitiate an alarm brokering procedure. Some alarm inhibit rules may alsodefine criteria for correlating groups of alarms or other data with oneanother. Such correlation rules may define that alarms that weregenerated as a result of a common alarm event should be correlated. Thealarm brokering system can subsequently use this correlation informationto send a single alarm for this correlated group of alarms, therebyreducing the number of notifications generated by the event.

Filtering rules can define filtering criteria to be applied to the datastreams. An example filtering rule may instruct that, for a specifieddata item representing a telemetry value, data values greater than 10should be discarded.

Monitoring rules can encompass a wide range of analytics to be performedon the data streams. In general, monitoring rules can be used to captureexpert knowledge about a monitored process associated with a given datastream. Such rules can be designed, for example, to perform analytics onselected items of time-series sensor data contained within the datastream over time, and to carry out actions based on results of theanalysis. Such actions may include sending notifications to selectedpersonnel in response to determining that one or more items oftime-series sensor data satisfies a condition, changing a processcontrol setpoint or parameter for the monitored industrial process inresponse to a detected condition of the time-series sensor data, orother such actions.

Processed data generated by the rule processing is stored in datastorage 1026. For tracking and record-keeping purposes, this can includeany alarm values that were filtered or inhibited by the rules, analysisresults, actions that were taken as a result of a rule-based analysis,or other such information.

Another produce/consume client pair (comprising produce client 1014 andconsume client 1018) routes the processed data from processing step 1016to downstream processes associated with the data pipeline. This caninclude sending the data to an index processing block 1022, which storesthe processed data in cloud storage 2026, making the data available forsubsequent searches. Consume client 1018 also sends the processed datato a match engine 1020 of the brokering system for alarm brokerprocessing. This processing can include identifying alarms that requiretechnical support attention, and matching these alarms to suitableexperts (as described above in connection with FIG. 3). Alarm brokering(as described above in connection with FIG. 3) will be performed afterthe alarm data from the pipeline has been harmonized, inhibited, andfiltered, and any defined monitoring rules associated with the pipelinehave been applied. Definition of monitoring rules will be described inmore detail below.

As noted above, the use of produce/consume clients to convey datathrough the data pipeline allows isolation between processing stepsperformed on the data streams. This allows selected processing blocks tobe modified without disrupting other processing blocks that make up thepipeline. For example, the harmonization processing block 1008 or therule processing block 1016 can be modified or upgraded to newer versionswithout the need to disable or disrupt other processing blocks. Tofurther isolate the data processing from version control, the systemleverages a manifest 1028, which allows processing of data streams to besegregated based on the source of the data contained in the streams. Ingeneral, each data stream—which is associated with a particularindustrial enterprise, facility, production area, or automationsystem—is assigned a manifest that maps the source of the data to aparticular set of rules or procedures to be applied to the data stream.In particular, the manifest identifies which procedures, of a set ofpredefined or generic procedures stored in rules storage 914—are to beinvoked and applied to the data at respective stages of the datapipeline as the torrential data is streamed to the data lake. As a datastream is being moved through the data pipeline, the analytics component212 invokes and references the manifest 1028 associated with that datastream in order to determine which stored rules or procedures in storage914 are to be applied to the data stream. The manifest 1028 containsinformation that identifies the subset of stored rules to be applied tothe stream, as well as information identifying which particular dataitems contained in the stream are to be mapped to the respectivevariables or parameters defined by the rules.

An example manifest 1028 associated with a given data stream conveyed bythe data pipeline can include a system manifest associated with theparticular data stream or data source, as well as associatedcustomer-specific tag manifests and metric manifests. FIG. 11 is aconceptual diagram of an example manifest 1028 comprising a systemmanifest 1104, one or more tag manifests 1106, and one or more metricsmanifests 1108. A system manifest 1104 can correspond to a particulardata stream being conveyed by the pipeline, and can include links tocustomer-specific and application-specific tag manifests 1106 andmetrics manifests 1108 that define actions that can be performed on someor all of the data contained in that data stream. As data from aparticular customer-specific data source (e.g., an industrial automationsystem, machine, device, or collection of industrial assets) is beingstreamed from the industrial site to the cloud-based data lake, theanalytics component 212 of the data pipeline and analytics system 202invokes the appropriate manifest (system manifest 1104, tag manifest1106, and metrics manifest 1108) for processing selected items of databeing conveyed in the data stream. In general, the metrics manifest 1108identifies one or more generic or user-defined rules that can beretrieved from rules storage 914 and executed on the torrential data, aswell as application-specific ranges, coefficients, and thresholds thatmay be passed to the retrieved procedures as parameters. The tagmanifest 1106 identifies tag names or other data item identifiers usedto map selected data items in the data stream to variables or tagsdefined in the retrieved rules.

FIG. 12 illustrates an example system manifest 1200. As shown, thesystem manifest 1200 conforms to a hierarchical structure wherein levelsof the hierarchy can be navigated based on metadata associated with thedata stream (e.g., customer identifier, site, etc.). The system manifest1200 can include links to one or more available tag manifests andmetrics manifests that can be selectively invoked to process datacontained in the data stream. As shown in the example system manifest1200, a particular metrics manifest 1208 and tag manifest 1210 isassociated with a customer ID 1202, site ID 1204, and virtual supportengineer (VSE) ID 1206. Additional hierarchical levels for message type1212 (e.g., alarms or historical data) and process ID 1214 are used bythe analytics component 212 to identify the respective namespaces 1216and associated rules that define how the data contained in the datastream is to be processed by the cloud-based data process services. Inthe example illustrated in FIG. 12, Alarm data is associated with thenamespace CoreProcessAssembly.AlarmDataProcess (assembly file nameCoreProcessAssembly.dll), while Historical data is associated with thenamespace CoreProcessAssembly.HistoricalDataProcess. Another namespacecan also be defined and associated with TSSD data or other data types.

FIG. 13 illustrates an example tag manifest 1300, which identifies thedata to be operated on by the identified metrics. In this example, thedata is identified using tag names 1302 that specify the particular dataitems within the data stream that are to be included in the rules-basedprocessing. The tag manifest 1300 also defines one or more applicationIDs 1308 representing applications that can be invoked and executed onthe data. The application IDs 1308 are respectively defined in terms ofone or more process IDs 1304 corresponding to stored generic oruser-defined rules that will be executed on the data when thecorresponding application ID is invoked. In the example tag manifestillustrated in FIG. 13, application ID 1.1 (named “TurboExpanderl”)comprises three rules—process ID 1 (“NetPower”), process ID 2(“CycleEfficiency”), and process ID 3 (“PowerGuarantee”). Theseprocesses—which correspond to rules defined and stored on the cloudplatform in rules storage 914—will be applied to the data correspondingto the tag names 1302 when the TurboExpander1 application is invoked.

FIG. 14 illustrates an example metrics manifest 1400, which defines thecoefficients, thresholds, and ranges to be used for each of the rulesspecified by the process IDs 1304 in the tag manifest 1300. For eachmetric ID 1402 (corresponding to the process IDs defined in the tagmanifest 1300), a set of coefficients 1404 and thresholds 1406 aredefined. For each defined coefficient, the metrics manifest 1400 definesa coefficient name, a unit, and a value. For each defined threshold, themetrics manifest 1400 defines a value and a unit.

In general, the manifest 1028 maps the source of a data stream with oneor more analytic procedures or rules to be applied to the data in thatstream. The rules are stored in rules storage 914 and invoked by themanifest 1028. Some of the rules defined and stored in rules storage maybe generic rules that are applicable to any data stream from any site orcustomer, while other rules may be specifically designed for particularsites or customers and are only applicable to data streams from thosesites or customers. In either case, the rules can be selected in an adhoc manner in accordance with the definitions encoded in the manifest1028. Generic rules can include generic parameters that define variableinputs into the analytic procedure defined by the rule, and thecustomer-specific manifest can define which customer-specific data itemsor tags within the manifest's data stream map to each of those genericparameters. These mappings may be defined, for example, in the tagmanifest portion of the manifest. When a manifest invokes a generic rulefor application to a particular customer's data stream, the generic rulecan reference the manifest in order to identify which customer-specificdata items are to be acted upon by the rule. Generic rules can be storedin rules storage 914 according to relevant industry, technology,industrial device, and/or any other suitable categorization or groups ofcategories.

The rules definition component 208 can generate and store the rules inaccordance with rule definition input received via the user interfacecomponent 214. For example, as will be described in more detail below,the user interface component 214 can generate and serve a set of userinterface screens that guide a user through the process of defining,modifying, and storing rules in rules storage 914. The rules definitioncomponent 208 also generates and tracks version control information foreach rule, including but not limited to an author of the rule, a datethat the rule was created or modified, a description of the rule and/orany modifications made to the rule, etc. In some embodiments, the rulesdefinition component 208 can include security features that preventnewly defined rules from being invoked by a manifest until the rule hasbeen approved by a designated supervisor.

FIG. 15 is an example user interface screen 1502 that can be generatedby the user interface component 214 and used to define rules that can beinvoked by the manifest for processing data streams. The particularexample screen illustrated in FIG. 15 depicts a list of alarm rules.Each row 1504 of interface screen 1502 corresponds to a defined rule,with each rule identified by a unique Rule ID. Network, Customer, Site,and Device columns can identify, hierarchically, the customer-specificsource of the data stream to which the rule is to be applied. TheNetwork column identifies a network of customers, and the Customercolumn identifies the particular customer within the identified networkto whom the rule is made available. The Site column identifies a plantfacility belonging to the identified customer, and the device identifiesa device within the facility that produces data contained in the datastream. The Action column can define an action to be performed on thealarm data in the data stream (e.g., inhibit, escalate, assign toengineer, etc.). Controls are included that allow the user to delete ordisable a selected alarm rule. Rules can be sorted or filtered accordingto any of the column headings.

Global rules can be defined and stored in rules storage 914, andselectively assigned to particular customers. FIG. 16 is an example userinterface screen that can be used to assign rules to a customer or sitevia drag-and-drop interaction. In this example, a list of availablecustomer sites are rendered on a Customer/Sites section 1602 of theinterface. The customers and site scan be rendered as a hierarchicaltree structure that organizes customer sites in accordance with suitablehierarchical levels (e.g., Customer Network level, Customer level,Region level, Site level). Selection of a customer site from theCustomer/Sites section 1602 causes the list of rules assigned to thatsite to be rendered in a List of Rules section 1604. Rules can beassigned to the selected customer site by selecting a rule from a RulesLibrary section 1606—which can render a list of available rules storedin rules storage 914—and dragging the selected rule to the List of Rulessection 1604. As shown in FIG. 16, multiple rules can be associated witha given customer site in an ad hoc manner For embodiments in which rulesmust be approved by a supervisor before being applied to a data stream,rules that have not yet been approved can be made visible in the RulesLibrary section 1606 but rendered in a manner indicating that theserules are not yet available for selection (e.g., by greying the text).

Users can add new rules to rules storage 914 by selecting the Add Rulecontrol 1506 on interface screen 1502. As shown in FIG. 17, selectingthis control 1506 can cause a Rule Configuration section to bedisplayed, where the Rules Configuration section includes a Group Levelssection 1702 and a Value Attributes section 1704. The Group Levelssection 1702 includes selection controls that allow the user to selectthe data source—in terms of Network, Customer, Site, and Device—to whichthe rule will be applied, and the Value Attributes section 1704 allowsthe user to add data value attributes that will trigger the rule. Asshown in FIG. 18, multiple value attributes can be added using the AddAttribute control 1802, and AND and/or OR operators can be used toaggregate the attributes. The Tag Name field specifies a particular dataitem within the data stream corresponding to the selections made in theGroup Levels section 1702, and the corresponding Value field defines thecondition of that data item that will cause the rule to be invoked.

Each attribute can be defined as a setpoint value or a range of values.Setpoint values will be cause the attribute to be TRUE when thecorresponding tag (specified by the Tag Name field) is greater than orequal to that value, while attributes set as ranges will be TRUE whenthe corresponding tag has a value within the defined range of values.When aggregated by the AND and OR operators, the value attributescollectively define one or more conditions, in terms of monitored valuesof data items within the selected data stream, that will cause the newrule to be triggered.

With the group levels and value attributes selecting, an Action control1804 can be selected to render a graphic that allows the user to selectthe action to be performed when the conditions defined by the valueattributes become TRUE. FIG. 19A is an example Action Configurationdisplay that can be used to set the action to be performed. An ActionSelection control 1902 can be used to select a particular action to becarried out when the defined conditions become true. Since the presentexample relates to an alarm rule, the options for the Action Selectioncontrol 1902 may include, for example Inhibit, Escalate, Assign toEngineer, etc. The Inhibit option causes a Number and Days fields (1904and 1906) to be displayed, allowing the user to select a duration forwhich the alarm will be inhibited (or to be inhibited indefinitely). Asshown in FIG. 19B, the Escalate option can cause the cloud-based alarmbrokering system to escalate the alarm to a selected engineer from adefined set of available engineers, where the engineer can be selectedusing field 1908.

Although the example rule configuration screens illustrate configurationof alarm monitoring rules, it is to be appreciated that similar screenscan be used to create TSSD monitoring rules for time-series sensor data.Information obtained via the configuration screens described above inconnection with FIGS. 15-19 can be used by the system to update the setof rules maintained in rules storage 914, and/or the manifest 1028 forthe appropriate data stream. The harmonization process described above(see, e.g., FIG. 8) can create dataframes for data items in the datastreams having the necessary schema that maps data attitudes to fieldsof the interface screens depicted in FIGS. 15-19.

FIG. 20 illustrates a methodology in accordance with one or moreembodiments of the subject application. While, for purposes ofsimplicity of explanation, the methodology shown herein is shown anddescribed as a series of acts, it is to be understood and appreciatedthat the subject innovation is not limited by the order of acts, as someacts may, in accordance therewith, occur in a different order and/orconcurrently with other acts from that shown and described herein. Forexample, those skilled in the art will understand and appreciate that amethodology could alternatively be represented as a series ofinterrelated states or events, such as in a state diagram. Moreover, notall illustrated acts may be required to implement a methodology inaccordance with the innovation. Furthermore, interaction diagram(s) mayrepresent methodologies, or methods, in accordance with the subjectdisclosure when disparate entities enact disparate portions of themethodologies. Further yet, two or more of the disclosed example methodscan be implemented in combination with each other, to accomplish one ormore features or advantages described herein.

FIG. 20 illustrates an example methodology 2000 for collecting andprocessing industrial data. Initially, at 2002, industrial data iscollected from one or more industrial devices of an industrialenterprise. The industrial data can be received, for example, from oneor more cloud agent devices located at a plant facility in which theindustrial devices reside. At 2004, the industrial data is transferredto a data lake as a torrential data stream. In an example embodiment,produce and consume clients can be used to facilitate this datastreaming The industrial data is placed on a data stream that isdedicated to a particular industrial enterprise, plant facility,industrial system, and/or industrial device. Data items contained in thedata stream can include, for example, alarm data, time-series sensordata, or other such information.

At 2006, data items within the data stream are harmonized to a commondata schema to facilitate collective data processing. At 2008, amanifest associated with the data stream is referenced, the datamanifest identifying a subset of defined rules to be applied to one ormore of the data items within the data stream. The manifest can beuniquely associated with the industrial enterprise, plant facility,industrial system, and/or industrial device from which the data streamis received. At 2010, the one or more data items are processed inaccordance with the subset of rules identified by the manifest, asdetermined based on the referencing at step 2008. Any type of processingcan be carried out by the various applied rules. For example, alarmmonitoring rules can be defined that generate a notification in responseto determining that one or more of the data items in the data streamsatisfy a defined criterion, and direct the notification to one or moretechnical specialists or other suitable personnel. Other rules can beused to calculate a defined metric based on specified data items of thedata stream.

At 2012, the data items and results of the rules-based processing arestored in data lake storage for subsequent viewing or retrieval. Also,at 2014, at least a subset of the data items and results of therules-based processing can be sent to an alarm broker system thatfacilitates matching identified alarm conditions to suitable expertscapable of assisting the industrial enterprise in addressing the alarmconditions.

Embodiments, systems, and components described herein, as well asindustrial control systems and industrial automation environments inwhich various aspects set forth in the subject specification can becarried out, can include computer or network components such as servers,clients, programmable logic controllers (PLCs), automation controllers,communications modules, mobile computers, wireless components, controlcomponents and so forth which are capable of interacting across anetwork. Computers and servers include one or more processors—electronicintegrated circuits that perform logic operations employing electricsignals—configured to execute instructions stored in media such asrandom access memory (RAM), read only memory (ROM), a hard drives, aswell as removable memory devices, which can include memory sticks,memory cards, flash drives, external hard drives, and so on.

Similarly, the term PLC or automation controller as used herein caninclude functionality that can be shared across multiple components,systems, and/or networks. As an example, one or more PLCs or automationcontrollers can communicate and cooperate with various network devicesacross the network. This can include substantially any type of control,communications module, computer, Input/Output (I/O) device, sensor,actuator, and human machine interface (HMI) that communicate via thenetwork, which includes control, automation, and/or public networks. ThePLC or automation controller can also communicate to and control variousother devices such as standard or safety-rated I/O modules includinganalog, digital, programmed/intelligent I/O modules, other programmablecontrollers, communications modules, sensors, actuators, output devices,and the like.

The network can include public networks such as the internet, intranets,and automation networks such as control and information protocol (CIP)networks including DeviceNet, ControlNet, and Ethernet/IP. Othernetworks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus,Profibus, CAN, wireless networks, serial protocols, and so forth. Inaddition, the network devices can include various possibilities(hardware and/or software components). These include components such asswitches with virtual local area network (VLAN) capability, LANs, WANs,proxies, gateways, routers, firewalls, virtual private network (VPN)devices, servers, clients, computers, configuration tools, monitoringtools, and/or other devices.

In order to provide a context for the various aspects of the disclosedsubject matter, FIGS. 21 and 22 as well as the following discussion areintended to provide a brief, general description of a suitableenvironment in which the various aspects of the disclosed subject mattermay be implemented.

With reference to FIG. 21, an example environment 2110 for implementingvarious aspects of the aforementioned subject matter includes a computer2112. The computer 2112 includes a processing unit 2114, a system memory2116, and a system bus 2118. The system bus 2118 couples systemcomponents including, but not limited to, the system memory 2116 to theprocessing unit 2114. The processing unit 2114 can be any of variousavailable processors. Multi-core microprocessors and othermultiprocessor architectures also can be employed as the processing unit2114.

The system bus 2118 can be any of several types of bus structure(s)including the memory bus or memory controller, a peripheral bus orexternal bus, and/or a local bus using any variety of available busarchitectures including, but not limited to, 8-bit bus, IndustrialStandard Architecture (ISA), Micro-Channel Architecture (MSA), ExtendedISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB),Peripheral Component Interconnect (PCI), Universal Serial Bus (USB),Advanced Graphics Port (AGP), Personal Computer Memory CardInternational Association bus (PCMCIA), and Small Computer SystemsInterface (SCSI).

The system memory 2116 includes volatile memory 2120 and nonvolatilememory 2122. The basic input/output system (BIOS), containing the basicroutines to transfer information between elements within the computer2112, such as during start-up, is stored in nonvolatile memory 2122. Byway of illustration, and not limitation, nonvolatile memory 2122 caninclude read only memory (ROM), programmable ROM (PROM), electricallyprogrammable ROM (EPROM), electrically erasable PROM (EEPROM), or flashmemory. Volatile memory 2120 includes random access memory (RAM), whichacts as external cache memory. By way of illustration and notlimitation, RAM is available in many forms such as synchronous RAM(SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rateSDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), anddirect Rambus RAM (DRRAM).

Computer 2112 also includes removable/non-removable,volatile/non-volatile computer storage media. FIG. 21 illustrates, forexample a disk storage 2124. Disk storage 2124 includes, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memorystick. In addition, disk storage 2124 can include storage mediaseparately or in combination with other storage media including, but notlimited to, an optical disk drive such as a compact disk ROM device(CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RWDrive) or a digital versatile disk ROM drive (DVD-ROM). To facilitateconnection of the disk storage 2124 to the system bus 2118, a removableor non-removable interface is typically used such as interface 2126.

It is to be appreciated that FIG. 21 describes software that acts as anintermediary between users and the basic computer resources described insuitable operating environment 2110. Such software includes an operatingsystem 2128. Operating system 2128, which can be stored on disk storage2124, acts to control and allocate resources of the computer 2112.System applications 2130 take advantage of the management of resourcesby operating system 2128 through program modules 2132 and program data2134 stored either in system memory 2116 or on disk storage 2124. It isto be appreciated that one or more embodiments of the subject disclosurecan be implemented with various operating systems or combinations ofoperating systems.

A user enters commands or information into the computer 2112 throughinput device(s) 2136. Input devices 2136 include, but are not limitedto, a pointing device such as a mouse, trackball, stylus, touch pad,keyboard, microphone, joystick, game pad, satellite dish, scanner, TVtuner card, digital camera, digital video camera, web camera, and thelike. These and other input devices connect to the processing unit 2114through the system bus 2118 via interface port(s) 2138. Interfaceport(s) 2138 include, for example, a serial port, a parallel port, agame port, and a universal serial bus (USB). Output device(s) 2140 usesome of the same type of ports as input device(s) 2136. Thus, forexample, a USB port may be used to provide input to computer 2112, andto output information from computer 2112 to an output device 2140.Output adapters 2142 are provided to illustrate that there are someoutput devices 2140 like monitors, speakers, and printers, among otheroutput devices 2140, which require special adapters. The output adapters2142 include, by way of illustration and not limitation, video and soundcards that provide a means of connection between the output device 2140and the system bus 2118. It should be noted that other devices and/orsystems of devices provide both input and output capabilities such asremote computer(s) 2144.

Computer 2112 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)2144. The remote computer(s) 2144 can be a personal computer, a server,a router, a network PC, a workstation, a microprocessor based appliance,a peer device or other common network node and the like, and typicallyincludes many or all of the elements described relative to computer2112. For purposes of brevity, only a memory storage device 2246 isillustrated with remote computer(s) 2144. Remote computer(s) 2144 islogically connected to computer 2112 through a network interface 2148and then physically connected via communication connection 2150. Networkinterface 2148 encompasses communication networks such as local-areanetworks (LAN) and wide-area networks (WAN). LAN technologies includeFiber Distributed Data Interface (FDDI), Copper Distributed DataInterface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and thelike. WAN technologies include, but are not limited to, point-to-pointlinks, circuit switching networks like Integrated Services DigitalNetworks (ISDN) and variations thereon, packet switching networks, andDigital Subscriber Lines (DSL).

Communication connection(s) 2150 refers to the hardware/softwareemployed to connect the network interface 2148 to the system bus 2118.While communication connection 2150 is shown for illustrative clarityinside computer 2112, it can also be external to computer 2112. Thehardware/software necessary for connection to the network interface 2148includes, for exemplary purposes only, internal and externaltechnologies such as, modems including regular telephone grade modems,cable modems and DSL modems, ISDN adapters, and Ethernet cards.

FIG. 22 is a schematic block diagram of a sample computing environment2200 with which the disclosed subject matter can interact. The samplecomputing environment 2200 includes one or more client(s) 2202. Theclient(s) 2202 can be hardware and/or software (e.g., threads,processes, computing devices). The sample computing environment 2200also includes one or more server(s) 2204. The server(s) 2204 can also behardware and/or software (e.g., threads, processes, computing devices).The servers 2204 can house threads to perform transformations byemploying one or more embodiments as described herein, for example. Onepossible communication between a client 2202 and servers 2204 can be inthe form of a data packet adapted to be transmitted between two or morecomputer processes. The sample computing environment 2200 includes acommunication framework 2206 that can be employed to facilitatecommunications between the client(s) 2202 and the server(s) 2204. Theclient(s) 2202 are operably connected to one or more client datastore(s) 2208 that can be employed to store information local to theclient(s) 1602. Similarly, the server(s) 2204 are operably connected toone or more server data store(s) 2210 that can be employed to storeinformation local to the servers 2204.

What has been described above includes examples of the subjectinnovation. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe disclosed subject matter, but one of ordinary skill in the art mayrecognize that many further combinations and permutations of the subjectinnovation are possible. Accordingly, the disclosed subject matter isintended to embrace all such alterations, modifications, and variationsthat fall within the spirit and scope of the appended claims.

In particular and in regard to the various functions performed by theabove described components, devices, circuits, systems and the like, theterms (including a reference to a “means”) used to describe suchcomponents are intended to correspond, unless otherwise indicated, toany component which performs the specified function of the describedcomponent (e.g., a functional equivalent), even though not structurallyequivalent to the disclosed structure, which performs the function inthe herein illustrated exemplary aspects of the disclosed subjectmatter. In this regard, it will also be recognized that the disclosedsubject matter includes a system as well as a computer-readable mediumhaving computer-executable instructions for performing the acts and/orevents of the various methods of the disclosed subject matter.

In addition, while a particular feature of the disclosed subject mattermay have been disclosed with respect to only one of severalimplementations, such feature may be combined with one or more otherfeatures of the other implementations as may be desired and advantageousfor any given or particular application. Furthermore, to the extent thatthe terms “includes,” and “including” and variants thereof are used ineither the detailed description or the claims, these terms are intendedto be inclusive in a manner similar to the term “comprising.”

In this application, the word “exemplary” is used to mean serving as anexample, instance, or illustration. Any aspect or design describedherein as “exemplary” is not necessarily to be construed as preferred oradvantageous over other aspects or designs. Rather, use of the wordexemplary is intended to present concepts in a concrete fashion.

Various aspects or features described herein may be implemented as amethod, apparatus, or article of manufacture using standard programmingand/or engineering techniques. The term “article of manufacture” as usedherein is intended to encompass a computer program accessible from anycomputer-readable device, carrier, or media. For example, computerreadable media can include but are not limited to magnetic storagedevices (e.g., hard disk, floppy disk, magnetic strips . . . ), opticaldisks [e.g., compact disk (CD), digital versatile disk (DVD) . . . ],smart cards, and flash memory devices (e.g., card, stick, key drive . .. ).

What is claimed is:
 1. A system for collecting and analyzing industrialdata, comprising: a memory that stores executable components; aprocessor, operatively coupled to the memory, that executes theexecutable components, the executable components comprising: a datastreaming component configured to transfer industrial data collectedfrom one or more industrial devices of an industrial enterprise to acloud platform as a data stream, wherein the data stream is associatedwith the industrial enterprise; a harmonization component configured toadd harmonization envelop data to respective data items of the datastream to yield harmonized data conforming to a common data schema; andan analytics component configured to reference a manifest associatedwith the industrial enterprise, to retrieve one or more analytic rulesidentified by the manifest from a rules store, and to apply the one ormore analytic rules to one or more of the data items of the data streamto yield one or more analytic results, wherein the data streamingcomponent is further configured to store the data items and the one ormore analytic results on cloud-based storage.
 2. The system of claim 1,wherein the data streaming component is further configured to transfermultiple sets of industrial data collected from respective sets ofindustrial devices as multiple data streams, and the executablecomponents further comprise a manifest component configured to createand store multiple manifests respectively associated with the multipledata streams.
 3. The system of claim 1, further comprising a userinterface component configured to generate one or more interfacedisplays that facilitate receipt of rule configuration input defininganalytic rules, wherein the analytic rules include the one or moreanalytic rules.
 4. The system of claim 3, the executable componentsfurther comprising a rules definition component configured to create andstore the analytic rules in accordance with the rule configurationinput.
 5. The system of claim 4, wherein the user interface displays areconfigured to receive, as the rule configuration input, selection of apredefined rule to be associated with the data stream, and wherein themanifest component is further configured to, in response to receipt ofthe selection, update the manifest to include a reference to thepredefined rule.
 6. The system of claim 1, wherein the analyticscomponent is further configured to, in response to determining that theone or more analytic results are indicative of an alarm condition, sendinformation relating to the alarm condition to an alarm brokeringsystem, wherein the alarm brokering system is configured to identify oneor more technical experts based on the information and to sendnotification data identifying the alarm condition to the one or moretechnical experts.
 7. The system of claim 1, wherein the analyticscomponents is further configured to, in response to determining that theone or more analytic results satisfy a criterion, generate and sendmodification data directed to one of the one or more industrial devices,the modification data configured to change a process control setpointstored on the industrial device.
 8. The system of claim 1, wherein theone or more analytic rules comprise at least one of an alarm inhibitrule configured to inhibit one or more alarms represented by the one ormore data items, a filtering rule configured to discard one or more ofthe data items based on a criterion defined by the filtering rule, or amonitoring rule configured to initiate an action in response todetermining that the one or more data items satisfy a criterion definedby the monitoring rule.
 9. The system of claim 1, wherein theharmonization envelope data comprises at least one of time zoneinformation indicating a time zone in which the data items originated,technology information indicating a technology to which the data itemsrelate, status information indicating a current service status of analarm event indicated by the data items, mode information indicating amode of the alarm event, or filter key information indicating a field ofthe data items to be used as a filter key for the data items.
 10. Amethod for monitoring industrial data, comprising: transferring, by asystem comprising at least one processor, industrial data collected fromone or more industrial devices of an industrial enterprise tocloud-based storage as a data stream, wherein the data stream isassociated with the industrial enterprise; appending, by the system,harmonization envelope data to data items of the data stream to yieldharmonized data that conforms to a common data schema; retrieving, bythe system, a subset of analytic rules stored on cloud-based rulestorage, wherein the subset of the analytic rules are identified by amanifest associated with the data stream; processing, by the system, oneor more of the data items in accordance with the one or more analyticrules to yield one or more analytic results; and storing, by the system,the data items and the one or more analytic results on the cloud-basedstorage.
 11. The method of claim 10, further comprising: transferring,by the system, multiple sets of industrial data collected fromrespective sets of industrial devices as multiple data streams; andstoring, by the system, multiple manifests in association with themultiple data streams, wherein each of the multiple manifest isassociated with one of the multiple data streams.
 12. The method ofclaim 10, further comprising: generating, by the system, one or moreinterface displays configured to receive rule configuration inputdefining one or more of the analytic rules; receiving the ruleconfiguration input via interaction with the one or more interfacedisplays; and creating and storing the one or more analytic rules inaccordance with the rule configuration input.
 13. The method of claim12, wherein the receiving the rule configuration input comprisesreceiving selection of a predefined rule to be associated with the datastream, and the method further comprises, in response to the receiving,modifying the manifest to add a reference to the predefined rule. 14.The method of claim 10, further comprising: in response to determiningthat the one or more analytic results indicate an alarm condition on atleast one of the one or more industrial devices, sending, by the system,information relating to the alarm condition to an alarm brokering systemthat sends notification data to one or more technical experts based onthe information.
 15. The method of claim 10, further comprising, inresponse to determining that the one or more analytic results satisfy acriterion, generating and sending modification data directed to one ofthe one or more industrial devices, the modification data configured tochange a process control setpoint of the industrial device.
 16. Themethod of claim 10, wherein the retrieving the subset of the analyticrules comprises retrieving at least one of an alarm inhibit ruleconfigured to inhibit one or more alarms represented by one or more ofthe data items, a filtering rule configured to discard one or more ofthe data items based on a criterion defined by the filtering rule, or amonitoring rule configured to initiate an action in response todetermining that one or more of the data items satisfy a criteriondefined by the monitoring rule.
 17. The method of claim 10, wherein theappending the harmonization envelope data comprises appending at leastone of time zone information indicating a time zone in which the dataitems originated, technology information indicating a technology towhich the data items relate, status information indicating a currentservice status of an alarm event indicated by the data items, modeinformation indicating a mode of the alarm event, or filter keyinformation indicating a field of the data items to be used as a filterkey for the data items.
 18. A non-transitory computer-readable mediumhaving stored thereon instructions that, in response to execution, causea system comprising a processor to perform operations, the operationscomprising: transferring industrial data collected from one or moreindustrial devices of an industrial enterprise to cloud-based storage asa data stream, wherein the data stream is associated with the industrialenterprise; appending harmonization envelope data to data items of thedata stream to yield harmonized data that conforms to a common dataschema; referencing a manifest associated with the data stream toidentify a subset of analytic rules stored on cloud-based rule storage;processing one or more of the data items in accordance with the subsetof analytic rules to yield one or more analytic results; and storing thedata items and the one or more analytic results on cloud-based storage.19. The non-transitory computer-readable medium of claim 18, theoperations further comprising: generating one or more interface displaysconfigured to receive rule configuration input defining one or more ofthe analytic rules; receiving the rule configuration input viainteraction with the one or more interface displays; and creating andstoring the one or more analytic rules in accordance with the ruleconfiguration input.
 20. The non-transitory computer-readable medium ofclaim 19, wherein the receiving the rule configuration input comprisesreceiving selection of a predefined rule to be associated with the datastream, and the operations further comprise, in response to thereceiving, modifying the manifest to add a reference to the predefinedrule.